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The No. 1/1A Electronic Switching System (ess) will play an 
important role in the evolving Stored Program Controlled (spc) 
Network because, as a major electronic switching system for local 
and combined local/ toll service, it provides direct interfaces to many 
of the Bell System's customers. It provides important capabilities 
required for System 800 Service and for a variety of other new spc 
network services. This paper describes several of the basic spc net- 
work capabilities provided by the No. 1/1A ess. It also describes the 
architecture and implementation of its common-channel interoffice 
signaling (ccis) subsystem, ccis call-processing software, and System 
800 software. 

I. INTRODUCTION 

The No. 1 ess was the Bell System's first major electronic switching 
system to provide commercial service. It went into service in 1965 and 
has served since then as a metropolitan local switching system. It uses 
Stored Program Control (spc) capabilities to provide basic telephone 
service, as well as numerous residential and business features. In 1976, 
an improved metropolitan local switching system, the No. 1A ess, 
went into service. It uses the same switching network as the No. 1 ess, 
but with a higher performance processor it has about twice the call 
capacity of No. 1 ess. Today, No. 1 and No. 1A esss serve nearly one- 
half of all Bell System subscriber lines. In addition, these systems also 
provide toll-switching capabilities when they are used as toll offices. 

In 1976, spc toll switching systems were first interconnected with a 
modern common-channel interoffice signaling (ccis) system. No. 1 ess 
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joined the resulting spc network with the introduction of ccis in 1978. 
No. 1A ess followed in 1979. The ccis system currently provides toll 
network signaling improvements, which result in such benefits as faster 
call setup, as well as trunk and service circuit cost savings. 

Ultimately, the major benefits to be derived from the use of modern 
common-channel signaling systems will be in the new features and 
customer services that they can provide. To fully realize these benefits, 
the spc network is being extended to include local switching offices 
which provide direct interfaces with the customer. The No. 1/1A esss 
will be the first local switching systems to utilize ccis with such service 
scheduled to begin in 1981. This will then permit local, as well as toll, 
calls to be handled using ccis. It will permit basic call-handling 
improvements such as providing busy tone from the originating office 
rather than from the terminating office, thus reducing trunk holding 
time for interoffice calls requiring busy treatment. It will also provide 
the customer interfaces required for implementation of many new spc 
network features and services. 

II. NETWORK CAPABILITIES 

The spc network improves basic call handling through the use of 
ccis. However, the major benefits of the spc network will be in the 
new services made possible because of capabilities provided by spc 
network nodes operating in unison. The SPC network plan is described 
in another article in this issue. 1 The following paragraphs describe spc 
network capabilities available in No. 1/1 A esss. 

2. 1 Basic signaling 

No. 1/1A esss have the ability to use ccis for basic call handling, as 
well as for special features. This includes a banded signaling capability 
which uses trunk band and member numbers to identify ccis trunks in 
call-processing messages. Banded signaling is described in an earlier 
article. 2 

The No. 1/1A ess has the ability to pass along banded messages for 
an established ccis trunk connection. This pass-along capability can 
be used by any switching office in a completely ccis trunk connection 
to look ahead or to look backward to an end office for information 
which can be used in processing the call. For example, a terminating 
office could use the pass-along capability to transmit a request for 
calling-party information from the originating office. This information 
could then be used to provide terminating office services, such as 
special alerting or special call handling. 

The No. 1/1A ess also has the capability for signaling directly to 
any other spc network node. Direct signaling does not require an 
established trunk connection. One example of its use would be for a 
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switching office to communicate with a nonswitching office node, such 
as a centralized data base. Using this capability, switching offices could 
obtain call-handling information needed for special types of calls. 
Switching offices, especially local switching offices, could use direct 
signaling to provide customer status information to such data bases. 
The data would then be immediately available to the entire spc 
network for processing calls. The System 800 features described in 
Section V of this article use direct signaling for providing customer 
status information to national data bases and for accessing those data 
bases to obtain call-handling information. Direct signaling is described 
in another article in this issue. 3 

2.2 SPC network interfaces 

The spc network provides faster, more efficient basic call handling. 
It will now also provide a variety of new and improved services. Rapid 
deployment of these services can be achieved through the use of 
centralized feature logic and national data bases at spc network nodes 
called network control points (ncps, see Fig. 1). Universal availability 
of spc network service depends on all subscribers having access to the 
spc network. Access for call handling is provided at spc network nodes 
called action points (acps). Stored program control local offices, such 
as No. 1/1A esss, could serve as acps, thus providing direct spc 
network access to customer lines. Customers served by non-spc local 
offices can also obtain access to spc network features via trunks to spc 
network toll office or traffic service position system (tsps) acps, as 
illustrated in Fig. 1. However, such indirect access may involve trunk- 
ing penalties, call setup delays, and/or overloading at toll offices and 
tspss. Therefore, it is advantageous to provide access to the spc 
network at the local office whenever a high percentage of that office's 
customers subscribe to or are likely to use spc network services. 

In addition to the acp call-handling interfaces, other spc network 
interfaces are required to provide service data to ncps. Such data 
might include customer class-of-service information or busy/idle line 
status. This type of information is often accessible only at the local 
office. Thus, for certain spc network services, the subscriber must be 
served by an spc network local office. Because No. 1/1A esss serve 
such a high percentage of the subscriber lines including lines to many 
business customers, they can play a major role in the spc network. 

System 800 will be the first service implemented on the No. 1/1 A 
ess to utilize the types of spc network interfaces described above. A 
busy /idle status indicator (bisi) feature will provide customer line 
status from local offices to national System 800 data bases in real time. 
An originating screening office (oso) feature, operating in either local 
or toll offices, will access these data bases to obtain call-handling 
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Fig. 1 — Stored Program Controlled Network interfaces. 

instructions for 800 Service calls. Section V describes the No. 1/1 A 
ess implementation of these features. 

2.3 Customer interfaces 

The objective of the spc network is to provide new and improved 
customer services. Some services can be provided by an intelligent 
network which contains a variety of customer data stored either in 
centralized data bases or in local switching offices. Other services will 
require new customer interfaces including new dialing sequences and 
voice dialogues for prompting customers and providing call status. 
These interfaces are part of the spc network dialing plan described in 
this issue. 4 Some services may also require nonvoice interfaces for 
communicating service-related information between the spc network 
and the customer. The following paragraphs describe some of the 
useful customer interface capabilities of No. 1/1 A ess local offices. 

The spc local offices have direct access to subscriber lines and to 
line-related data stored within the office. Line access allows local 
offices to collect service-related data through special dialing sequences 
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from customers using either rotary dial or Touch-Tone* telephones. 
Toll offices may also collect digits via trunk connections, but this is 
only practical from Touch-Tone phones. The tsps may also collect 
such information from customers verbally. 

Direct line access permits special alerting, such as distinctive ringing. 
Since alerting is strictly a local office function, special alerting for spc 
network services must be provided from spc network local offices. 

Access to line-related data contained within local offices allows these 
offices to provide such data to other spc network nodes when required 
for special features. For example, an originating office could provide 
calling number information to an ncp as part of a call-processing query 
or to a terminating office in response to a pass-along request for such 
information. Local offices could provide busy/idle line status either on 
request or whenever line status changes. They could also provide 
customer class-of-service information indicating the types of services 
that customers have subscribed to or currently have active. 

In addition to line-related customer interfaces, SPC network features 
may require special data interfaces with the customer. As illustrated 
in Fig. 1, the No. 1/1A ess could provide such interfaces to customer 
computers or keyboard terminals. These interfaces could be used for 
exchanging service control and/or status information. The No. 1/1 A 
ess currently provides such interfaces to private network customers 
and System 800 customers. 

III. SIGNALING SUBSYSTEM ARCHITECTURE 
3.1 Objectives 

The objectives of the No. 1/1 A ess signaling subsystem include 
providing hardware-independent signaling capabilities to a variety of 
No. 1/1 A ess application programs. These include programs such as 
ccis call processing and System 800 features that use ccis directly. 
They also include many other feature programs that use ccis indi- 
rectly, e.g., via general-purpose trunk supervisory programs. 

Because toll offices handle greater volumes of interoffice calls, they 
generally have greater signaling capacity requirements than local 
offices. However, local offices have more stringent data-link equipment 
cost constraints than toll offices. Two different data-link hardware 
subsystems have been developed to meet these differing needs in No. 
1/1 A ess offices. Certain software must be included in a switching 
office when a particular data-link subsystem is used. Other software is 
common to both subsystems. Software packaging must be provided 
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that allows an office to load only the software required for its particular 
equipment arrangement. 

The following sections describe the signaling subsystem architecture 
that satisfies these objectives. 

3.2 General description 

The No. 1/1 A signaling subsystem comprises several layers of con- 
trol as illustrated in Fig. 2. This structure allows ess applications 
software to send and receive ccis messages without being concerned 
about Input/Output (i/o) details or data-link administration proce- 
dures. 

The ess applications software that uses the signaling subsystem 
includes call processing, maintenance, network management, and other 
feature programs. Supervisory programs provide special signaling in- 
terfaces for application programs that perform trunk-related signaling 
without knowledge of whether a trunk is a ccis trunk or not. 

The signaling software layer provides hardware-independent signal- 
ing capabilities. It provides macro-accessible subroutines for format- 
ting and transmitting ccis messages. It also reads ccis messages from 
the data-link equipment and delivers them to appropriate ess appli- 
cations programs. 

The data-link software layer provides all hardware-dependent inter- 




Fig. 2 — Signaling subsystem layers of control. 
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faces for each type of ccis data-link equipment. It also provides data- 
link administration and maintenance capabilities. 

Each of the ccis data-link hardware subsystems used in No. 1/1A 
ess is microprocessor controlled. The data-link hardware, along with 
its firmware programs, implements much of the ccis protocol including 
message queuing, data transmission, error detection, and error correc- 
tion through retransmission. The firmware also includes diagnostic 
programs that can be invoked by data-link layer software. 

The following paragraphs further describe each of the signaling 
subsystem layers beginning with the lowest layer — the data-link hard- 
ware. 

3.3 Hardware 

The No. 1/1A ess currently supports two types of ccis data-link 
hardware. One is a 2400 b/s data link called the ccis data terminal 
frame (dtf). It is the result of a common development for initial ccis 
service on ccis signal transfer points (stps), No. 4A/Electronic Tan- 
dem Switching (ets), No. 4 ess, and No. 1/1A ess toll switching 
offices. The ccis-dtf satisfies the common needs of toll network stps 
and ccis switching offices, i.e., high volumes of trunk-related signaling 
traffic. The ccis dtf is used only for ccis signaling. 

The other type of data link used for ccis is the peripheral unit 
controller-data link (puc-dl). The peripheral unit controller (puc) was 
developed to provide microprocessor control of digital carrier trunks 
(dcts). The puc was later modified to provide microprocessor control 
for data-link applications. The resulting puc-dl was first used to 
communicate with a remote switching system (rss) and was later 
adapted for ets private network service and then for ccis service. A 
single puc-dl frame can be shared among all three applications. Each 
application has its own type of data terminal or line interface unit. 
The ccis puc-dl terminal, like the ccis-dtf terminal, operates at 2400 
b/s. 

Because of several years advance in technology between develop- 
ment of the ccis-dtf and the puc-dl, the puc-dl is not only smaller 
than the ccis-dtf but its per-terminal cost is less than the ccis-dtf 
per-terminal cost. The cost advantage of a ccis puc-dl terminal is 
increased when the puc-dl frame is shared with other applications in 
the same office. Thus, the puc-dl is not only a cost-effective terminal 
for local offices, but it can be used as a cost-reduced terminal for No. 
1/1A ess toll offices as well. 

Figure 3 illustrates the No. 1/1A ess's signaling subsystem architec- 
ture used for ccis. This illustration is applicable to both the ccis-dtf 
and the ccis puc-dl. The data-link equipment provides the interface 
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Fig. 3 — Signaling subsystem hardware. 

between the ESS central control and the Voice Frequency Links (vfls) 
used for data transmission. 

Each type of signaling subsystem used for ccis comprises a duplex 
data-link controller and one or more pairs of data-link terminals. The 
ccis data links are always assigned in pairs, with the number of pairs 
determined by the volume of signaling traffic in the office. Each link 
of a pair connects the ess to a ccis stp. Signaling traffic is shared on 
each link of the pair, both of which are concurrently active. Each link 
includes two geographically diverse vfls — one active and one standby. 
This permits rapid link recovery in the event of transmission failures. 
The signaling network is described in greater detail in an earlier 
article. 5 

Data and control information is exchanged between the central 
control and the signaling subsystem via the peripheral unit bus. Many 
peripherals are connected to the bus. Thus, the central control uses a 
central pulse distributor to enable a particular peripheral to access the 
bus when there is data or control information on the bus for it. 

Both the ccis-dtf and the puc-dl provide microprocessor-con- 
trolled, self-diagnosing data links. The ccis-dtf has a hard-wired 
controller and a microprocessor-controlled terminal. The ccis-dtf 
terminal's program is loaded from the central control when it is 
initialized. The puc-dl has a microprocessor-controlled data-link con- 
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troller and terminal, each of which contains permanently resident 
programs. The functions performed by the microprocessor programs 
are described in Section 3.4. 

The data-link hardware provides electrical interfaces and low-level 
signaling operations necessary to implement the ccis protocol. These 
operations include parallel-to-serial conversion of ccis signal units 
transmitted over the electrical interface between the data terminal 
and the modem and serial-to-parallel conversion of signal units re- 
ceived over this interface. The modems perform digital-to-analog and 
analog-to-digital conversion of the transmitted- and received-bit 
streams. They also maintain bit synchronization on the vfl. 

3.4 Firmware 

The firmware is the collection of programs that reside in the data- 
link hardware. The firmware implements the link-level ccis protocol.* 
This level provides error-free data transmission over a signaling link 
in the ccis network. 

The ccis-dtf and ccis puc-dl firmware formats ccis signal units 
and messages into fixed-length blocks for transmission over the link. 
The firmware generates a cyclic redundancy check (crc) codef used 
for detecting transmission errors on each signal unit, and it retransmits 
messages containing signal units received in error at the other end of 
the link. 

The firmware provides priority-level queuing of messages waiting to 
be transmitted on the link and of messages received on the link that 
are waiting to be unloaded by the central control software. It buffers 
all transmitted messages until they are acknowledged so that they are 
available for retransmission if required. It also provides positive ac- 
knowledgment of all signal units received correctly and negative ac- 
knowledgment of all signal units received in error on the link. 

The firmware collects message traffic counts and error statistics, 
such as the number of address messages transmitted and the number 
of signal units received in error. This information is provided to the 
central control software upon request. The firmware detects and 
reports problems such as circuit failures, buffer overflows, and ex- 
ceeded-error thresholds. The firmware also responds to software re- 
quests for data-link control and maintenance actions such as initiali- 
zation, reconfiguration, and diagnosis. 

3.5 Data-link software 

The data-link software layer is responsible for maintaining an op- 



* For a description of the ccis system protocol, see Ref. 2. 

t In the puc-dl, the firmware computes the crc code. In the ccis-dtf, the hardware 
computes the crc code under control of the firmware. 
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erational signaling subsystem. It is also responsible for providing 
signaling subsystem status and hardware-dependent i/o interfaces to 
the outer layers of software illustrated in Fig. 2. The major components 
of this layer are the link security and maintenance software. There are 
ccis-dtf and puc-dl programs in each of these categories. 

Link security software provides ccis data-link administration, which 
includes fault detection and automatic link recovery procedures. The 
objective of these procedures is to quickly remove faulty link compo- 
nents from service and to maintain an operational signaling subsystem 
by providing an alternate path for affected signaling traffic. 

Link security maintains ess signaling subsystem status and signaling 
network status for use in output message routing by the signaling 
software layer. This includes status reflecting the operational states of 
the data-link equipment in the ess office. It also includes status of the 
operational states of other links in the signaling network that affect 
the routing of trunk-related (banded) messages that emanate from the 
ess. Such signaling network status is received in messages from the 

STPS. 

One of the principal link security procedures for maintaining an 
operational signaling subsystem is automatic link recovery. This pro- 
cedure is initiated when link security detects a service affecting data- 
link fault or alarm. Since ccis links are always equipped in pairs, the 
link recovery procedure begins by setting the failed link's operational 
status to out of service and placing the link in a faulty link mode of 
operation. This immediately causes banded messages destined for the 
failed link to be routed to its mate link and direct-signaling messages 
to be distributed over all other available links. It also causes change- 
over signals to be transmitted on the failed link, if possible, in order to 
notify the stp of the failure in the event that the stp had not already 
detected it. Link security then transfers all messages awaiting trans- 
mission or retransmission and unacknowledged transmitted messages 
from the failed link to its mate. 

The part of the recovery procedure described above immediately 
restores the lost signaling capability. The next step in the procedure is 
to restore the lost link as quickly as possible. Since the most common 
source of link failure is the vfl, each ccis link has a duplicate vfl as 
illustrated in Fig. 3. When both ends of a link have detected a failure, 
they will attempt to resynchronize on the backup vfl. If that attempt 
is unsuccessful, they will alternately attempt to resynchronize on the 
original vfl and then again on the backup vfl. The ess alternates 
between vfls every 5 seconds, and the stp alternates between vfls 
every 10 seconds to guarantee intervals when both ends are attempting 
to resynchronize on the same vfl. In most cases, this procedure 
restores the link. Following a successful resynchronization on either 
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vfl, a 15-second prove-in period is entered to verify acceptable trans- 
mission quality on the link. Following a successful prove-in period, the 
link security software notifies the stp at the other end of the link that 
signaling traffic may be returned to the link by transmitting a load 
transfer signal. When the stp returns a load transfer acknowledgment 
signal, link security allows the ess to resume signaling on the link by 
setting the link status to active. If link resynchronization is unsuccess- 
ful after 3 minutes of attempting, link security requests maintenance 
programs to diagnose the affected data-link equipment. 

The software maintenance programs control execution of data-link 
diagnostic programs that reside within the data-link equipment. The 
diagnostic programs verify access to different points within the data- 
link equipment, and they also execute data-link equipment tests. 
Diagnostics can be requested by link security software or manually via 
a teletypewriter. The maintenance programs also support manual 
controls for data-link configuration and testing. For example, they 
respond to requests to remove data links from service, to switch vfls, 
and to provide maintenance access to the vfls for manual testing. 
These maintenance functions are done in conjunction with the link 
security software. 

3.6 Signaling software 

The signaling software layer provides hardware-independent signal- 
ing capabilities to the ess applications software. This includes i/o 
interfaces for ccis trunk-related (banded) signaling and direct signal- 
ing. The signaling software also provides automatic responses to sig- 
naling network congestion. The principal programs in this layer are a 
ccis input processor, a ccis output processor, and signaling network 
congestion control programs. 

The ccis input processor is a continuous process within the ess 
central control. It executes at regular intervals, each time checking for 
input from the ccis data links. When input messages are present, the 
input processor unloads the messages from the data links. Within the 
programs that unload the data links, there are short hardware-depend- 
ent segments of program code that are both logically and physically 
part of the data-link software layer. Each program or program segment 
resides in a software feature package. This concept is explained in 
Section 3.8. 

The input processor distributes ccis input messages to appropriate 
application programs. Included in the input processor is a finite-state 
machine (fsm) controller that provides inputs to application programs 
such as ccis call processing, which uses an FSM-based software archi- 
tecture. For these applications, the specific program that receives an 
input message is a function of the current state of the fsm at the time 
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the input is received. The fsm controller also performs state updates 
when the application program has completed processing of the input 
message. The call processing fsm is described in Section 4.3. 

The ccis output processor consists of macro-accessible subroutines 
which are called by the application programs when they wish to send 
a ccis message to a different spc network node. The output processor 
provides a high-level interface that permits the application programs 
to be concerned mainly about the application-oriented data content of 
messages and not about the low-level signaling protocol characteristics. 

The output processor will optionally format user-specified data into 
ccis message format. It then routes the messages to an appropriate 
signaling link based on data-link equipment status and signaling net- 
work status maintained by the data-link software layer and also based 
on a terminal load-balancing algorithm. The load-balancing algorithm 
strives to maintain an evenly balanced load among all available ccis 
links. Banded messages are associated with a specific data-link pair; 
thus, such messages are evenly distributed to the two terminals of the 
pair. Direct-signaling messages may be routed over any available ccis 
link; therefore, these messages balance the signaling load across ter- 
minal pairs. The output processor calls data-link-dependent output 
subroutines in the data-link software layer to transmit data. These 
subroutines execute peripheral orders to effect the transfer of data 
across the peripheral unit bus to the data-link equipment. 

Signaling network congestion control programs automatically re- 
spond to signaling overload in the ess data links and in the ccis 
network stps. Data-link overloads are detected as buffer-full conditions 
in the data links. Overloads in stps directly connected to the ess are 
reported to the ess using processor signaling congestion messages. 
Because of the load-balancing algorithms used within the signaling 
network, it is assumed that whenever a data link or stp becomes 
overloaded that its mate is also overloaded. Thus, the response to 
either of these conditions is to reduce traffic to both of the affected 
links while such congestion lasts. Signaling traffic is reduced by pre- 
venting new call originations which would use the affected terminal 
pair and by preventing direct-signaling traffic from using that terminal 
pair. Overloads in stps not directly connected to a particular ess can 
still affect signaling for specific trunks in that ess whose ccis messages 
must be routed through the overloaded stps. The ess is notified of 
such overloads through group signaling congestion messages. These 
messages apply to specific trunk groups. The ess response to one of 
these messages is to place a 10-second network management trunk 
group control on the affected group. This temporarily suspends sig- 
naling traffic for that trunk group by either canceling new call origi- 
nations destined for the group or optionally skipping the group in the 
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call-routing sequence and permitting the call to complete on a different 
trunk group. 

3. 7 ESS applications software 

The applications software consists of ess programs that use the 
signaling subsystem for basic call handling, for implementing special 
features, etc. Two principal applications are ccis call processing and 
System 800. These applications are described in Sections IV and V, 
respectively. There are also other important applications which use 
ccis. For example, ccis network management provides traffic controls 
on the ccis portion of the trunking network. Trunk maintenance 
programs in switching offices at each end of ccis trunks use the 
signaling network to exchange maintenance state information about 
the trunks. Trunk query is an interoffice trunk state audit which 
verifies that the operational and/or maintenance states at each end of 
ccis trunks are consistent. Other ess call-processing programs use the 
signaling subsystem for trunk-related signaling via the supervisory 
program interfaces described in Section 4.2. 

In addition to application layer programs, signaling software and 
data-link software layer programs themselves use the signaling sub- 
system. 

3.8 Software feature packaging 

No. 1/1 A esss serve a variety of purposes. They provide basic local, 
tandem, and toll switching, as well as a variety of network features 
such as ccis and customer services such as System 800. Each office is 
individually engineered and equipped with the hardware and software 
required for the features and services provided by that office. Feature 
packaging is a mechanism used to permit an office to load that 
software, and only that software, needed to provide the office's partic- 
ular combination of features and services. 

A feature package is a collection of software associated with a 
particular feature, service, or piece of equipment. The software may 
include complete programs, program segments, and/or subroutines. It 
can also include fixed and variable amounts of temporary (call store) 
memory. A feature, service, or piece of equipment may require one or 
more feature packages to be loaded into an office. Also, a particular 
feature package may be used by one or more different features, 
services, or pieces of equipment. The following paragraphs describe 
the feature packages which provide ccis capabilities in local and toll 
offices, the packages associated with the signaling system hardware, 
and the System 800 packages. 

ccis Common — This package contains software required by every 
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No. 1/1 A ESS office equipped with the signaling capability. It includes 
hardware-independent signaling software and ccis applications soft- 
ware, such as call-processing programs, which are common to local, 
tandem, and toll switching, trunk maintenance, network management, 
etc. 

Local ccis — This package contains ccis call-processing logic re- 
quired in local offices. It handles calls routed over ccis interlocal, 
tandem, and toll-connecting trunks. 

Toll ccis — This package contains ccis call-processing logic required 
in toll offices. It handles calls routed over ccis intertoll and toll- 
connecting trunks. 

ccis Two- Wire — This package contains maintenance programs re- 
quired to diagnose faults in two-wire ccis trunks and continuity check 
circuits used with ccis trunks. Two-wire networks are used mainly for 
local switching. 

ccis hilo — This package contains maintenance programs required 
to diagnose faults in hilo ccis trunks and continuity check circuits. 
The hilo switching networks provide transmission quality equivalent 
to four- wire networks and are used for toll switching in No. 1/1 A ess 
offices. 

2400DL — This package contains maintenance software for the 2400 
b/s ccis-dtf. 

ccis 2400dl — This package contains hardware-dependent i/o inter- 
faces and link security logic associated with the ccis-dtf. 

puc — This package contains maintenance software associated with 
the peripheral unit controller. This software is common to the dct 
application and also to each of the puc-dl applications. 

puc-dl — This package contains maintenance software associated 
with the puc when it is used as a data-link controller. The software is 
required for any application that uses the puc-dl. 

ccis puc-dl — This package contains hardware-dependent i/o inter- 
faces, link security logic, and maintenance programs associated with 
the ccis configuration of the puc-dl. 

oso — This package contains the software which comprises the Sys- 
tem 800 originating screening office feature. It is used in all No. 1/1A 
ess local and toll offices that have the ccis signaling capability. 

bisi — This package contains the software which comprises the Sys- 
tem 800 busy /idle status indicator feature. It is used in local offices 
that serve System 800 customers. 

The required combination of the above feature packages depends 
on the type of office, the data-link hardware subsystem used, and the 
features or services provided by that office. Figure 4 illustrates the 
feature package combination required for a typical local switching 
office with ccis. It uses puc-dl for its ccis data links. It provides 
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originating office screening of 800 Service calls, and it serves customers 
that have 800 Service lines connected to the office. 

Every No. 1/1A ess has a collection of base software which provides 
basic call processing, maintenance, and switching office administration. 
Feature packages usually build on capabilities provided by the base 
software. As illustrated in Fig. 4, feature packages can also build on 
the capabilities provided by other feature packages. For example, the 
ccis puc-dl package adds data-link capabilities which are unique to 
ccis onto the more general puc-dl capabilities provided by the puc- 
dl package. The puc-dl package adds general data-link capabilities to 
the more general puc capabilities provided by the puc package. The 
puc package, in turn, builds on basic maintenance capabilities provided 
by the ess base software. Likewise, ccis applications such as oso and 
bisi use the signaling capabilities provided by the ccis common 
package in order to implement their own features. 

IV. CCIS CALL PROCESSING 
4. 1 Development environment 

ccis is sometimes referred to as a new signaling type to replace 
multifrequency (mf) signaling. While this may be partly true, address 
signaling (digit transmission) is certainly not the entire concept, nor 
the most difficult aspect, for call processing to implement. Digit 
transmission and voice path assurance for CCIS involve only a few 
messages and, as with mf signaling, comprise only the addressing 
portion of the call. It is the expanded capabilities of ccis (e.g., backward 
call failure messages) that make ccis difficult to integrate into existing 
systems which before only dealt with in-band signaling and supervision 
(e.g., trunk on-hook/off-hook signals). 
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Fig. 4— Software feature packaging for an spc network local office. 
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The ccis call processing is involved in setup and teardown of calls 
utilizing ccis trunks and mainly handles ccis trunk-related (banded) 
messages. This processing involves supervisory messages such as trunk 
seizure, answer, and disconnect which have non-ccis trunk on-hook/ 
off-hook signaling counterparts. However, ccis call processing also 
involves new nonsupervisory information messages such as specific 
call failure, trunk reset, and address messages which may not have 
non-ccis trunk signaling counterparts. 

The ccis call processing is faced with other issues not previously 
dealt with by existing call processing. Because of signal transmission 
errors and resultant retransmission, ccis signals can arrive out of 
sequence, be received twice, or even spill over from previous calls. 
Unexpected signals can arrive at any time, and special timing may be 
required to determine their reasonableness. 

No. 1/1 A ess first developed ccis for the toll environment. It was 
decided then that because of the number of signals and internal inputs 
to be processed during all phases of the calls, a finite-state machine 
structure would be best suited for the implementation. Also, since the 
toll environment is very limited in the types of connections required 
(i.e., trunk-to-trunk only), the processing logic could be mostly separate 
from the existing toll-processing logic. This eliminated extensive 
changes in the existing toll-call processing logic to handle supervision, 
out-of-sequence messages, new nonsupervisory messages, etc. As soon 
as the call-processing logic determines that a call involves a ccis trunk, 
control is passed to the toll ccis logic which then maintains control of 
the call through disconnect processing. 

Local ccis development was faced with an even larger and more 
complex environment. The local call-processing environment involves 
many program interfaces and types of connections requiring hundreds 
of thousands of program instructions. For example, besides basic calls 
such as line-to-trunk and trunk-to-trunk, there are interfaces with 
features such as coin, three-way calling, call waiting, etc. Duplicating 
this logic to process local ccis calls would have been too costly initially 
and most likely would have incurred huge maintenance costs. Thus, it 
was clear that the existing logic had to process local ccis calls and, 
further, coexist with the toll ccis logic already deployed. Supervisory 
messages received would have to be converted to their on-hook/off- 
hook counterparts and passed through some interface to the existing 
logic. Similarly, trunk circuit state changes to send supervisory signals 
outward would require conversion to ccis messages. Nonsupervisory 
messages (i.e., those with no on-hook/off-hook equivalent) would 
require special handling apart from the existing logic. This special 
handling would have to be confined to areas where signaling-type 
differences are recognized. 
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4.2 Supervision modernization 

The call-processing logic which handles calls involving in-band sig- 
naling trunks must also be used to process calls involving local ccis 
trunks. To accomplish this, the mechanisms for controlling supervision 
had to be changed. No longer could the application logic assume on- 
hook/off-hook supervision on the trunks. Application programs could 
no longer directly access i/o memory to change supervisory status. 
Turning off scanning of a trunk would not necessarily suspend super- 
vision, nor would changing the supervisory state in a trunk circuit 
necessarily send a supervisory signal to the connected office. An 
interface between the application programs and the signal i/o pro- 
grams to isolate supervision had to be developed. 

The incoming signal control mechanism which existed had two levels 
of programs that communicated using shared memory. The i/o level 
programs detected trunk supervisory changes, updated i/o memory, 
and reported the changes to the application program level. Application 
programs controlled report generation by writing directly into i/o 
memory. The application programs had to be familiar with the use of 
the memory and the synchronization problems which arose from 
multiple access by both levels. 

The objective of supervision modernization was to eliminate the 
tight coupling that existed among application programs, i/o processes, 
and i/o memory. Incoming signal control programs provide the pri- 
mary interface between i/o and application programs. The application 
programs control which reports are generated by making requests to 
the supervisory control program. This control program accesses i/o 
memory when necessary. Knowledge of i/o memory use and synchro- 
nization problems is thereby confined to the signal-processing interface 
programs. These supervisory interface programs maintain per trunk 
supervisory status in dedicated memory. Incoming signals from ccis 
trunks are recorded in this memory and delivered as logical reports to 
the call-processing programs. Implementation of this objective effec- 
tively isolates the details of supervision from the call-processing pro- 
grams which allows ccis and non-ccis trunks to be treated identically 
by the call-processing software. 

A second supervisory interface, the outgoing signal function, is used 
to generate outgoing supervisory signals. This interface is used when- 
ever call processing is attempting to change the supervisory state of an 
interoffice trunk which could possibly be a ccis trunk. The outgoing 
signal function allows the call-processing program to specify the logical 
supervisory message it wants to send and the trunk for which it should 
be sent. The outgoing signal interface causes the ccis signaling logic to 
send the appropriate ccis supervisory message for a ccis trunk. 
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4.3 Structure 

The ccis call-processing logic structure is based on finite-state 
machines. Each state represents a condition or processing stage of a 
ccis trunk involved in a call. The state of each ccis trunk is stored in 
a per-trunk state word block of memory. The states are grouped into 
models which reflect call functions (e.g., continuity checking). All 
stimuli handled by each model come as inputs through the ccis input 
processor where validity screening and state table execution take place. 

The ccis messages are unloaded from the data links by the input 
processor as described in Section 3.6. The trunk label from a call- 
processing message is translated to a trunk network appearance and a 
state word memory address. The message input is applied to the 
current state which specifies the model in control. The model controls 
all processing by calling any number of closed transition routines (i.e., 
those which return to the calling program), updating the state, and 
possibly calling an open interface routine (i.e., one which allows proc- 
essing to pass to other application logic). 

Models are of two basic types: processing models and conversion 
models (see Fig. 5). Processing models handle the parts of call proc- 
essing which are unique to the signaling type. The ccis address 
message processing and trunk-continuity checking are the primary 
examples. They have in-band signaling counterparts that are handled 
by separate programs. During these portions of a call, the processing 
models act as application programs and perform call-processing func- 
tions. These models are in control prior to sending or receiving the 
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Fig. 5 — Local ccis call-processing structure. 
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address complete (adc) message. The adc message basically separates 
call setup from answer and disconnect processing. Since most nonsu- 
pervisory messages are exchanged prior to adc, the processing of these 
messages is confined to the ccis application programs. All supervisory 
and nonsupervisory inputs are handled directly by these models. 

Conversion models are in control when the only messages to be 
processed are the supervisory messages. These models validate and 
resequence messages if necessary before passing them through the 
supervisory incoming signal interface to the call-processing programs. 
They also receive the stimulus from the outgoing signal interface to 
send the appropriate ccis supervisory message. These models maintain 
trunk states for message-screening purposes only and provide no call- 
processing functions themselves. In essence, the states of these models 
are unaware of whether the ccis trunk is connected to a line or to 
another trunk. This terminal processing concept enables local ccis to 
interact with the majority of the application programs of the local ess 
environment. 

4.4 Call flow 

The basic call types described in this section are those of the local 
office. A brief call flow of each type is given specifying the basic 
program interactions and message protocol. The toll office call-type 
descriptions have been previously given in other articles and are not 
repeated here for No. 1/1 A ESS. 6 

4.4. 1 Originating outgoing calls 

An originating outgoing ccis call begins the same as any originating 
outgoing call. Dial tone is given to the customer, digits are collected 
and analyzed, and an outgoing route is selected. When this outgoing 
route involves a ccis trunk, the ccis outpulsing logic receives control. 
The ccis outpulsing finite-state model and associated transition rou- 
tines perform the necessary call-processing functions and remain in 
control until the receipt of the adc message. These functions include 
sending the initial address message (iam), performing the continuity 
check if necessary, sending the continuity (cot) message, and handling 
any backward failure messages. Once adc has been received or an 
error has occurred, control is returned to the call-processing programs 
to perform call setup or teardown as required. 

During these and subsequent call functions, a conversion model 
handles the supervisory message inputs. The answer charge (anc) 
message, for example, causes the conversion model to pass a logical 
answer via the supervisory incoming signal interface to the call-proc- 
essing programs where answer processing occurs. Upon receipt of 
disconnect, the call-processing programs tear down the cross office 

NETWORK CAPABILITIES 1629 



path and restore the outgoing trunk to the idle state. Here, interface 
logic for ccis takes control of the outgoing trunk, sends a clear forward 
(clf) message, and places the trunk in a processing model which waits 
for the release guard (rlg) message. When rlg is received, the trunk 
is returned to the idle state and made available for another call. 

4.4.2 Incoming terminating calls 

This call begins with the receipt of an iam for a particular incoming 
ccis trunk. A continuity check circuit is connected to the incoming 
trunk, if required, and the call waits for the cot message. This function 
is handled by the ccis incoming call-processing model as a unique 
inpulsing-type application program which remains in control until the 
cot message is received. Upon receipt of the cot message, the adc 
message is sent to the originating office. Then control is given to the 
call-processing programs to perform digit analysis and establish nec- 
essary connections. Giving up control means that a conversion model 
handles subsequent inputs. However, in the event that digit analysis 
determines that the terminating line is busy, the subscriber busy (ssb) 
message is returned in lieu of the adc message so that the customer 
can be connected to busy tone in the originating office. If the called 
line is idle, the ccis incoming trunk is connected to audible ringing 
tone and ringing is applied to the terminating line. The calling cus- 
tomer then waits for the called party to answer. 

If the called party answers, the call-processing logic sets up the cross 
office path and puts the incoming trunk in the off-hook state. At this 
point, an outgoing signal interface to send logical answer allows the 
conversion model to send the anc message. Upon receipt of a clf 
message (i.e., calling party disconnect), the model passes a logical 
disconnect via the supervisory incoming signal interface to the call- 
processing programs. These programs tear down the cross office path 
and restore the incoming trunk to the idle state. An interface for ccis 
in the trunk idle logic sends the rlg message, and the trunk is made 
available for another call. 

4.4.3 Tandem calls 

An incoming call which routes back out of the office on an outgoing 
trunk is a tandem call. This call proceeds as an incoming terminating 
call, except that digit analysis dictates that an outgoing trunk be 
selected. When the outgoing trunk is a ccis trunk, the ccis outpulsing 
logic receives control to handle the outgoing trunk processing as 
described in originating outgoing calls, Section 4.4.1. The tandem call- 
processing logic performs the call setup and teardown processing. Each 
ccis trunk is independently associated with a finite-state model. The 
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models separately handle the ccis messages and supervisory interfaces 
for each trunk. 

V. NO. 1/1 A ROLE IN SYSTEM 800 

No. 1/1 A ess performs two important functions in System 800: the 
oso function and the bisi function. The oso function can exist in both 
No. 1/1A ess local and toll offices. An oso queries an ncp on all 800 
Service calls to obtain a direct distance dialing (ddd) number for 
routing. The bisi feature, which monitors the busy/idle status of 800 
Service customers and reports changes in status to an ncp, can reside 
in No. 1/1 A ess local offices. The busy/idle status can then be used by 
the ncp to provide alternate handling of 800 Service calls that would 
have received busy treatment. An overall description of the System 
800 capability is provided in another article in this issue. 7 The following 
sections describe the No. 1/1A ess implementation of the oso and bisi 
features. 

5. 1 Originating screening office 

The oso feature provides single-number ddd calling and improved 
routing for 800 Service calls. This section discusses the functioning of 
a No. 1/1 A ess oso as it applies to both local and toll offices. 

5.1.1 Processing 800 service calls 

A No. 1/1A ess oso processes both originating 800 Service calls and 
800 Service calls which arrive over a trunk from a distant office. The 
800 Service calls are recognized by examining the first three digits 
dialed by the customer or received from the distant office. After 
identifying a call as 800 Service, the oso determines the identity of the 
originating Numbering Plan Area (npa). 

The npa and the dialed 800 number are then formatted into an 800 
Service direct-signaling message called QUERY which is sent to an 
ncp. The npa is used by the ncp to determine if the call is allowed, 
based on the customer's purchased service area. The 800 Service call 
is suspended until a REPLY message is received from the ncp. The 
oso saves the call data, while the QUERY is being processed by the 
ncp, and times for a response from the ncp. 

When the oso receives a REPLY from the ncp, it first determines 
which call the REPLY is associated with by accessing the saved call 
data. If the REPLY contains a 10-digit ddd number, the oso routes 
the call as a normal ddd call. If a ddd number is not contained in the 
REPLY (e.g., because of all 800 Service lines being busy), the oso 
routes the call locally to an appropriate tone or announcement. 

The oso also has the ability to manually test the oso-ncp interface. 
The input of an 800 number and an npa from a teletypewriter will 
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cause the ess to send a QUERY to the ncp. The information contained 
in the resulting REPLY is then displayed on a teletypewriter at the 
oso. 

5.1.2 800 Service code controls 

The 800 Service code controls are initiated automatically to prevent 
overloading the switching network, the ccis signaling network, or the 
ncps. Code controls restrict the number of queries sent to a particular 

NCP. 

There are two types of 800 Service code controls: 

(i) Network management-code controls — These controls can be 
initiated automatically by the ncp or manually at the oso. When they 
are in effect, the oso limits the number of queries sent to the ncp for 
a particular 800 number or for a group of 800 numbers. 

(ii) ccis failure-code controls — These are initiated automatically 
when the oso is unable to successfully send a QUERY. They cause 
the oso to restrict queries for a group of 800 numbers. 

5.2 Busy /Idle status indicator feature 

The bisi feature resides in No. 1/1A ess 800 service terminating- 
end offices (teos). An 800 Service teo is a local office which serves 
800 Service customers. The bisi feature monitors the busy /idle status 
of 800 Service customer line groups and reports changes in busy /idle 
status to an ncp. The ncp can then use the busy/idle status information 
to provide alternate handling to 800 Service calls which would have 
received busy treatment. 

5.2. 1 Busy /idle monitoring and reporting 

With the introduction of System 800, all 800 Service calls will be 
routed to the teo using a 10-digit ddd number. In a No. 1/1 A ess teo, 
each 800 Service ddd number has an associated Simulated Facilities 
Group (sfg). The sfg is used to limit the number of simultaneous calls 
to a group of physical 800 Service lines and to provide proper 800 
Service band hunting and billing. An 800 Service band is a geographical 
area from which an 800 Service customer may receive calls. The ddd 
number also directs the incoming call to the correct physical facilities 
(i.e., lines). 

An sfg is required for each service-area band that an 800 Service 
customer purchases, so that incoming calls can be billed based on 
band. Figure 6 illustrates an 800 Service customer setup at the teo. 
This customer has seven physical lines and wishes to allow at most 
five of these lines to be used at any given time for incoming 800 Service 
calls. The customer wishes to permit three simultaneous calls from 
band 1 and two simultaneous calls from band 2, and to have band 1 
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Fig. 6 — 800 Service customer line group arrangement. 

calls overflow to band 2 lines if all band 1 lines are busy. In this case, 
two sfgs are required, and the band 1 sfg overflows to the band 2 sfg. 
There are three 800 Service lines in the band 1 sfg and two 800 Service 
lines in the band 2 sfg. A distinct ten-digit ddd number is required for 
each band. 

The bisi feature monitors the busy/idle status of the 800 Service 
sfgs in a teo. To perform the monitoring function, a count of the 
number of calls currently in progress for each sfg is maintained. This 
count is called USAGE. Also, for each sfg, a constant is stored which 
indicates the number of 800 Service lines for that sfg. This per-SFG 
constant is called MAX. The bisi feature monitors the activity on the 
sfg and increments or decrements USAGE when 800 Service lines are 
seized or released. 

The bisi feature reports changes in sfg busy/idle status to a remote 
ncp via ccis direct-signaling messages. Therefore, if USAGE becomes 
equal to MAX when an 800 Service line is seized, or if an 800 Service 
call is unable to complete because USAGE=MAX, a direct-signaling 
message is sent to the ncp that indicates BUSY. If USAGE becomes 
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equal to MAX-1 when an 800 Service line is released, an IDLE direct- 
signaling message is sent. The teo continuously audits USAGE so that 
its value is correct at all times. 

To assure that the BUSY and IDLE messages for a particular sfg 
are properly sequenced, the teo performs a blind-period timing func- 
tion. An sfg goes on blind period timing after a BUSY direct-signaling 
message is sent. While an sfg is on blind-period timing, no BUSY or 
IDLE direct-signaling messages are sent to the ncp. When the blind- 
period timing interval expires, an IDLE direct-signaling message is 
sent if the busy/idle status changed to idle while the sfg was on 
timing. 

The ncp has the ability to query the teo about the current busy/ 
idle status of a particular sfg. When the bisi direct-signaling QUERY 
message is received at the teo, the current busy /idle status is returned 
in either a BUSY or IDLE message. Using this mechanism, inconsist- 
encies in busy /idle status between the ncp and the teo can be 
corrected. 

5.2.2 Activation and deactivation of busy/idle reporting 

The teo reports changes in busy/idle status to the ncp only if busy/ 
idle reporting is activated for the sfg. Before busy/idle reporting can 
be activated for an sfg, common data between the ncp and the teo 
must be verified, so that busy/idle reporting will function correctly. 
The data verification sequence is performed using direct-signaling 
messages and can be initiated from either the ncp or the teo. 

Under normal circumstances, the ncp controls the activation/deac- 
tivation process, but the teo can also activate and deactivate busy/ 
idle reporting for an sfg. As an example, when the teo wishes to 
change some data (e.g., to add another line) associated with a particular 
activated 800 Service sfg, the sfg must first be deactivated. Next, a 
data verification process is initiated by the teo. The ncp returns its 
data for that sfg, and the teo verifies that the data returned agree 
with the data stored at the teo. If so, the sfg is activated and busy/ 
idle reporting resumes. 

5.2.3 800 Service data for customers 

The 800 Service customers can receive data concerning the activity 
on their lines, sfg attempt and overflow data are available using 
customer premises equipment. The counts can be sent to the customer 
as often as every 30 minutes. In addition, overflow counts are available 
on the customer's monthly bill. 

Prior to the new System 800, all counts were kept solely at the teo. 
With System 800, most overflows for customers served by teos with 
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the bisi feature occur at the ncp since the ncp screens all 800 Service 
calls. 

To provide this overflow data to the customers, the ncp sends it to 
the teo in a direct-signaling message either every 15 minutes or every 
day. The counts are then stored at the teo so that the customer can 
continue to get an accurate picture of the activity on their 800 Service 
lines. 

VI. SUMMARY 

No. 1 ess was the Bell System's first major commercial electronic 
switching system. Today No. 1 and 1A esss are an important part of 
the rapidly growing spc network. The spc network uses ccis to provide 
rapid and efficient basic call handling. However, the network's full 
capabilities are just beginning to be realized now that the spc network 
is being used for the development of services such as System 800. No. 
1/1A esss play an important role in the spc network because they 
provide direct interfaces to the subscribers and users of spc network 
services. No. 1/1 A esss serve nearly one-half of the Bell System 
subscriber lines. Thus, they have the potential to provide much cus- 
tomer-related service information and line status information to other 
spc network switching offices and ncps. 

The No. 1/1A ess uses a layered ccis signaling subsystem that 
supports two types of data-link hardware at the innermost layer, while 
providing hardware-independent signaling capabilities to ess applica- 
tions software at the outer layers. 

The ccis call processing provides call handling over ccis trunks in 
both local and toll offices. To do this, especially for local offices, the 
ccis programs have to interface with numerous existing ess call- 
processing programs which had previously used ingrained in-band 
signaling techniques. Changes to the ess supervisory programs helped 
to provide new signaling interfaces to these programs. 

The ccis call processing must also respond to the many call-handling 
messages which are part of the ccis protocol. It uses a finite-state 
machine program structure to respond to ccis messages and, at the 
same time, to verify their reasonableness when received at different 
stages of a call. 

No. 1/1A ess performs two important System 800 functions. With 
the help of ncps, it can screen 800 Service calls in either local or toll 
offices using its oso feature. With oso, System 800 ncps are queried to 
obtain call-routing information for 800 Service calls. The oso feature 
also provides code controls on 800 Service calls. 

A System 800 bisi feature monitors System 800 customer line groups 
served by No. 1/1A ess local offices and reports busy/idle line status 
changes to System 800 ncps for use in call screening. The bisi feature 
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also provides 800 Service call attempt and overflow data to customer 
premises equipment. The System 800 features exemplify the types of 
spc network and customer interfaces that No. 1/1A ess can provide. 
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